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Transparent Interconnection of Lots of Links (TRILL): 
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Abstract 


The IETF TRILL (Transparent Interconnection of Lots of Links) 
protocol provides least-cost pair-wise data forwarding without 
configuration in multi-hop networks with arbitrary topologies and 
link technologies. TRILL supports multipathing of both unicast and 
multicast traffic. Devices that implement the TRILL protocol are 
called TRILL switches or RBridges (Routing Bridges). 


ESADI (End Station Address Distribution Information) is an optional 
protocol by which a TRILL switch can communicate, in a Data Label 
(VLAN or fine-grained label) scoped way, end station address and 
reachability information to TRILL switches participating in ESADI for 
the relevant Data Label. This document updates RFC 6325, 
specifically the documentation of the ESADI protocol, and is not 
backwards compatible. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7357. 
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Les 


Introduction 


The TRILL (Transparent Interconnection of Lots of Links) protocol 
[RFC6325] provides least-cost pair-wise data forwarding without 
configuration in multi-hop networks with arbitrary topologies and 
link technologies, safe forwarding even during periods of temporary 
loops, and support for multipathing of both unicast and multicast 
traffic. TRILL accomplishes this with the IS-IS (Intermediate System 
to Intermediate System) [IS-IS] [RFC1195] [RFC7176] link-state 
routing protocol using a header with a hop count. The design 
supports optimization of the distribution of multi-destination frames 
and two types of data labeling: VLANs (Virtual Local Area Networks) 
[RFC6325] and FGLs (fine-grained labels) [RFC7172]. Devices that 
implement TRILL are called TRILL switches or RBridges (Routing 
Bridges). 


There are five ways a TRILL switch can learn end station addresses, 
as described in Section 4.8 of [RFC6325]. One of these is the ESADI 
(End Station Address Distribution Information) protocol, which is an 
optional Data Label scoped way by which TRILL switches can 
communicate with each other information such as end station addresses 
and their TRILL switch of attachment. A TRILL switch that is 
announcing interest in a Data Label MAY use the ESADI protocol to 
announce the end station address of some or all of its attached end 
stations in that Data Label to other TRILL switches that are running 
ESADI for that Data Label. (In the future, ESADI may also be used 
for other address and reachability information.) 


By default, TRILL switches with connected end stations learn 
addresses from the data plane when ingressing and egressing native 
frames, although such learning can be disabled. The ESADI protocol’s 
potential advantages over data plane learning include the following: 


1. Security advantages: 


a) The ESADI protocol can be used to announce end stations with an 
authenticated enrollment (for example, enrollment authenticated 
by cryptographically based EAP (Extensible Authentication 
Protocol) [RFC3748] methods via [802.1X]). 


b) The ESADI protocol supports cryptographic authentication of its 
message payloads for more secure transmission. 


2. Fast update advantages: The ESADI protocol provides a fast update 
of end station MAC (Media Access Control) addresses and their 
TRILL switch of attachment. If an end station is unplugged from 
one TRILL switch and plugged into another, ingressed frames with 
that end station’s MAC address as their destination can be 
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black-holed. That is, they can be sent just to the older egress 
TRILL switch that the end station was connected to until cached 
address information at some remote ingress TRILL switch times out, 
possibly for tens of seconds [RFC6325]. 


MAC address reachability information, some ESADI parameters, and 
optional authentication information are carried in ESADI packets 
rather than in the TRILL IS-IS protocol. As specified below, ESADI 
is, for each Data Label, a virtual logical topology overlay in the 
TRILL topology. An advantage of using ESADI over using TRILL IS-IS 
is that the end station attachment information is not flooded to all 
TRILL switches but only to TRILL switches advertising ESADI 
participation for the Data Label in which those end stations occur. 


1.1. Content and Precedence 


This document updates [RFC6325], the TRILL base protocol 
specification, replacing the description of the TRILL ESADI protocol 
(Section 4.2.5 of [RFC6325], including all subsections), providing 
more detail on ESADI, updating other ESADI-related sections of 
[RFC6325], and prevailing over [RFC6325] in any case where they 
conflict. For this reason, familiarity with [RFC6325] is 
particularly assumed. These changes include a change to the format 
of ESADI-LSPs (ESADI Link State Protocol Data Units) that is not 
backwards compatible; this change is justified by the substantially 
increased amount of information that can be carried and in light of 
the very limited, if any, deployment of RFC 6325 ESADI. These 
changes are further discussed in Appendix A. 


Section 2 of this document is the ESADI protocol overview. Section 3 
specifies ESADI DRB (Designated RBridge) determination. Section 4 
discusses the processing of ESADI PDUs. Section 5 discusses 
interaction with other modes of end station address learning. 
Section 6 describes the ESADI-LSP and its contents. 

1.2. Terminology 


This document uses the acronyms defined in [RFC6325], in addition to 
the following: 


Data Label: VLAN or FGL. 


ESADI RBridge: An RBridge that is participating in ESADI for one 
or more Data Labels. 


FGL: Fine-Grained Label [RFC7172]. 


LSP: Link State PDU [IS-IS]. 
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LSP number zero: A Link State PDU with fragment number equal to 


Zero. 
PDU: Protocol Data Unit. 
TRILL switch: An alternative name for an RBridge. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Capitalized IANA-related terms such as "IETF Review" are to be 
interpreted as described in [RFC5226]. 


2. ESADI Protocol Overview 


ESADI is a Data Label scoped way for TRILL switches (also known as 
RBridges) to announce and learn end station addresses rapidly and 
securely. An RBridge that is announcing participation in ESADI for 
one or more Data Labels is called an ESADI RBridge. 


ESADI is an optional protocol that is separate from the mandatory 
TRILL IS-IS implemented by all RBridges in a campus. There is a 
separate ESADI instance for each Data Label (VLAN or FGL) if ESADI is 
being used for that Data Label. In essence, for each such Data 
Label, there is a modified instance of the IS-IS reliable flooding 
mechanism in which ESADI RBridges may choose to participate. (These 
are not the instances specified in [RFC6822].) Multiple ESADI 
instances may share implementation components within an RBridge as 
long as that sharing preserves the independent operation of each 
instance of the ESADI protocol. For example, the ESADI link state 
database could be a single database with a field in each record 
indicating the Data Label to which it applies, or it could be a 
separate database per Data Label. However, the ESADI update process 
operates separately for each ESADI instance and independently from 
the TRILL IS-IS update process. 


ESADI does no routing calculations, so there is no reason for 
pseudonodes in ESADI and none are created. (Pseudonodes [IS-IS] are 
a construct for optimizing routing calculations.) Furthermore, a 
relatively large amount of ESADI data will have to be distributed, 
under some circumstances, using ESADI mechanisms; this would require 
a large number of ESADI-LSP fragments. ESADI-LSP, ESADI-CSNP, and 
ESADI-PSNP (ESADI Link State PDU, Complete Sequence Number PDU, and 
Partial Sequence Number PDU) payloads are therefore formatted as 
Extended Level 1 Circuit Scope (E-L1CS) PDUs [RFC7356] (see also 
Section 6). This allows up to 27716 fragments but does not support 
link state data associated with pseudonodes. 
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After the TRILL Header, ESADI packets have an inner Ethernet header 
with the Inner.MacDA of "All-Egress-RBridges" (formerly called 
"A11-ESADI-RBridges"), an inner Data Label specifying the VLAN or FGL 
of interest, and the "L2-IS-IS" Ethertype followed by the ESADI 
payload, as shown in Figure 1. 


AA AAA Aa Aa AA aa aa aaa -o + 
| Link Header | 
AA AAA AA aa Aa aa aa Aa + 
| TRILL Data Header | 
AA AAA Aa Aa AA Aa Aaa Aa -------- + 
| Inner Ethernet Addresses | 
AAA AA Aa Aa AA Aaa Aa aaa + 
| Data Label | 
AA AA Aa aa AA aaa aaa aa + 
| L2-IS-IS Ethertype | 
HO + 
| ESADI Payload | 
AA AA Aa Aa aa aa Aaa Aa + 
| Link Trailer | 
AAA AA Aa Aa AA Aa Aaa Aa -------- + 


Figure 1: TRILL ESADI Packet Overview 
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TRILL ESADI packets sent on an Ethernet link are structured as shown 
in Figure 2. The outer VLAN tag will not be present if it was not 
included by the Ethernet port that sent the packet. 


Outer Ethernet Header: 

HH O A O O O O O O O O O O O O O e e o o o o o ++ 

| Next Hop Destination Address 

++ A AO O O AO O O O O O O O O e e e e o o ho +4 

| Next Hop Destination Addr. | Sending RBridge Port MAC Addr. | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Sending RBridge Port MAC Address 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
..-Ethernet frame tagging including optional Outer.VLAN tag... 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Ethertype = TRILL 0x22F3 | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| v | R |M|Op-Length| Hop Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Egress Nickname | Ingress (Origin) Nickname | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Inner Ethernet Header: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| All-Egress-RBridges 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| All-Egress-RBridges (cont.) | Origin RBridge MAC Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Origin RBridge MAC Address (continued) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Ethertype = L2-IS-IS 0x22F4 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

ESADI Payload (formatted as IS-IS): 
+-+-4+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Frame Check Sequence: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

FCS (Frame Check Sequence) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 2: ESADI Ethernet Link Packet Format 
The Next Hop Destination Address or Outer.MacDA is the All-RBridges 
multicast address if the ESADI PDU is being multicast. If it is 


being unicast, the Next Hop Destination Address is the unicast 
address of the next-hop RBridge. The VLAN for the Outer.VLAN 
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information, if present, will be the Designated VLAN for the link on 
which the packet is sent. The V and R fields will be zero while the 
M bit will be one, unless the ESADI PDU was unicast, in which case 
the M bit will be zero. The Data Label specified will be the VLAN or 
FGL to which the ESADI packet applies. The Origin RBridge MAC 
Address or Inner.MacSA MUST be a MAC address unigue across the campus 
owned by the RBridge originating the ESADI packet -- for example, any 
of its port MAC addresses if it has any Ethernet ports -- and each 
ESADI RBridge MUST use the same Inner.MacSA for all of the ESADI 
packets it originates. 


TRILL ESADI packets sent on a PPP link are structured as shown in 
Figure 3 [RFC6361]. 


PPP Header: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| PPP = TNP (TRILL Data) 0x005D 


AA 
TRILL Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| v | R |M|Op-Length| Hop Count | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Egress Nickname | Ingress (Origin) Nickname 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Inner Ethernet Header: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| All-Egress-RBridges 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| All-Egress-RBridges (cont.) | Origin RBridge MAC Address | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Origin RBridge MAC Address (continued) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| VLAN or FGL Data Label (4 or 8 bytes) [RFC7172] 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Ethertype = L2-IS-IS 0x22F4 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

ESADI Payload (formatted as IS-IS): 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

PPP Check Sequence: 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

PPP Check Sequence 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Figure 3: ESADI PPP Link Packet Format 
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2.1. ESADI Virtual Link 


All RBridges forward ESADI packets as if they were ordinary TRILL 
Data packets. Because of this forwarding, it appears to an instance 
of the ESADI protocol at an RBridge that it is directly connected by 
a multi-access virtual link to all RBridges in the campus that are 
"data reachable" from it (see Section 2 of [RFC7180]) and are running 
ESADI for that Data Label. No "routing" calculation (least-cost path 
or distribution tree construction) ever has to be performed by ESADI. 
An ESADI RBridge merely transmits the ESADI packets it originates on 
this virtual link as described for TRILL Data packets in [RFC6325] 
and [RFC7172]. For multicast ESADI packets, it may use any 
distribution tree that it might use for an ordinary multi-destination 
TRILL Data packet. RBridges that do not implement the ESADI 
protocol, do not have it enabled, or are not participating in the 
ESADI protocol for the Data Label of an ESADI packet do not 
decapsulate or locally process the ESADI packet. Thus, ESADI packets 
are transparently tunneled through transit RBridges. 


2.2. ESADI Neighbor Determination 


The ESADI instance for Data Label X at an RBridge RB1 determines who 
its adjacent ESADI neighbors are by examining the TRILL IS-IS link 
state database for RBridges that are data reachable from RB1 (see 
Section 2 of [RFC7180]) and are announcing their participation in 
Data Label X ESADI. When an RBridge RB2 becomes data unreachable 
from RB1 or the relevant entries for RB2 are purged from the core 
IS-IS link state database, it is lost as a neighbor and also dropped 
from any ESADI instances from the point of view of RB1, and when RB2 
is no longer announcing participation in Data Label X ESADI, it 
ceases to be a neighbor for any Data Label X ESADI instance. All 
these considerations are Data Label scoped. Because of these 
mechanisms whereby an ESADI instance at an ESADI RBridge can 
determine its ESADI adjacencies by examining the TRILL IS-IS link 
state database, there are no "Hellos" sent in ESADI and no adjacency 
information is carried in ESADI-LSPs. 


A participation announcement in a VLAN scoped ESADI instance is 
generated by setting a flag bit in the Interested VLANs sub-TLV, and 
an announcement for an FGL scoped ESADI instance is generated by 
setting a flag bit in the Interested Labels sub-TLV [RFC7176] (see 
Section 7.1). 
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2.3. ESADI Payloads 


TRILL ESADI packet payloads are structured like IS-IS Extended 

Level 1 Circuit Scope (E-L1CS) LSP, CSNP, and PSNP PDUs [RFC7356], 
except as indicated below, but are always TRILL encapsulated on the 
wire as if they were TRILL Data packets. The information distributed 
by the ESADI protocol includes a list of local end station MAC 
addresses connected to the originating RBridge and, for each such 
address, a l-octet unsigned "Confidence" rating in the range 0-254 
(see Section 6.2). It is entirely up to the originating RBridge 
which locally connected MAC addresses it wishes to advertise via 
ESADI and with what Confidence. It MAY advertise all, some, or none 
of such addresses. In addition, some ESADI parameters of the 
advertising RBridge (see Section 6.1) and, optionally, authentication 
information (see Section 6.3) are included. Future uses of ESADI may 
distribute other similar address and reachability information. 


TRILL ESADI-LSPs MUST NOT contain a Data Label ID in their payload. 

The Data Label to which the ESADI data applies is the Data Label of 

the TRILL Data packet enclosing the ESADI payload. If a Data Label 

ID could occur within the payload, it might conflict with that TRILL 
Data packet Data Label and could conflict with any future Data Label 
mapping scheme that may be adopted [VLANmapping]. If a VLAN or FGL 

ID field within an ESADI-LSP PDU does include a value, that field's 

contents MUST be ignored. 


3. ESADI DRB (Designated RBridge) Determination 


Because ESADI does no adjacency announcement or routing, the 
ESADI-DRB never creates a pseudonode. However, a DRB [RFC7177] is 
still needed to issue ESADI-CSNP PDUs and respond to ESADI-PSNP PDUs 
for ESADI-LSP synchronization. 


Generally speaking, the DRB election on the ESADI virtual link (see 
Section 2.1) operates similarly to the DRB election on a TRILL IS-IS 
broadcast link, as described in Section 4.2.1 ("DRB Election 
Details") of [RFC7177], with the following exceptions: in the Data 
Label X ESADI-DRB election at RB1 on an ESADI virtual link, the 
candidates are the local ESADI instance for Data Label X and all 
remote ESADI instances at RBridges that are (1) data reachable from 
RB1 [RFC7180] and (2) announcing in their TRILL IS-IS LSP that they 
are participating in ESADI for Data Label X. The winner is the 
instance with the highest ESADI Parameter 7-bit priority field with 
ties broken by the System ID, comparing fields as unsigned integers 
with the larger magnitude considered higher priority. "SNPA/MAC 
address" (Subnetwork Point of Attachment / MAC address) is not 
considered in this tiebreaking, and there is no "Port ID". 
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4. ESADI PDU Processing 


Data Label X ESADI neighbors are usually not connected directly by a 
physical link but are always logically connected by a virtual link 
(see Section 2.1). There could be hundreds or thousands of ESADI 
RBridges (TRILL switches) on the virtual link. The only PDUs used in 
ESADI are the ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDUs. In 
particular, there are no Hello or MTU PDUs, because ESADI does not 
build a topology, does not do any routing calculations, and does not 
determine MIU. Instead, ESADI uses the distribution trees and the Sz 
campus minimum link MTU determined by the core TRILL IS-IS (see 
[RFC6325] and [RFC7180]). 


4.1. Unicasting ESADI PDUs 


For [IS-IS], PDU multicasting is normal on a local link and no effort 
is made to optimize to unicast, because on the typical physical link 
for which IS-IS was designed (commonly a piece of multi-access 
Ethernet cable), any frame made the link busy for that frame time. 
However, to ESADI instances, what appears to be a simple multi-access 
link is generally a set of multi-hop distribution trees that may or 
may not be pruned. Thus, transmitting a multicast frame on such a 
tree can impose a substantially greater load than transmitting a 
unicast frame. This load may be justified if there are likely to be 
multiple listeners but may not be justified if there is only one 
recipient of interest. For this reason, under some circumstances, 
ESADI PDUs MAY be TRILL unicast if it is confirmed that the 
destination RBridge supports receiving unicast ESADI PDUs (see 
Section 6.1). 


The format of a unicast ESADI packet is the format of a multicast 
TRILL ESADI packet as described in Section 2 above, except as 
follows: 


o On an Ethernet link, in the outer Ethernet header the Outer.MacDA 
is the unicast address of the next-hop RBridge. 


o In the TRILL Header, the M bit is set to zero and the Egress 
Nickname is the nickname of the destination RBridge. 
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To support unicasting of ESADI PDUs, Section 4.6.2.2 of [RFC6325] is 
replaced with the following: 


4.6.2.2. TRILL ESADI Packets 


If M= 1, the egress nickname designates the distribution tree. 
The packet is forwarded as described in Section 4.6.2.5. In 
addition, if (1) the forwarding RBridge is interested in the 
specified VLAN or fine-grained label [RFC7172], (2) the forwarding 
RBridge implements the TRILL ESADI protocol, and (3) ESADI is 
enabled for the specified VLAN or fine-grained label, then the 
inner frame is decapsulated and provided to that local ESADI 
protocol. 


If M = 0 and the egress nickname is not that of the receiving 
RBridge, the packet is forwarded as for known unicast TRILL Data 
frames as described in Section 4.6.2.4. If M = 0 and the egress 
nickname is that of the receiving RBridge, and the receiving 
RBridge supports unicast ESADI PDUs, then the ESADI packet is 
decapsulated and processed if it meets the three numbered 
conditions in the paragraph above; otherwise, it is discarded. 


The references to "4.6.2.2", "4.6.2.4", and "4.6.2.5" above refer to 
those sections in [RFC6325]. 


4.2. General Transmission of ESADI PDUs 


Following the usual [IS-IS] rules, an ESADI instance does not 
transmit any ESADI PDUs if it has no ESADI adjacencies. Such 
transmission would just be a waste of bandwidth. 


The MTU available to ESADI payloads is at least 24 bytes less than 
that available to TRILL IS-IS because of the additional fields 
required ( 2(TRILL Ethertype) + 6(TRILL Header) + 6(Inner.MacDA) + 
6(Inner.MacSA) + 4/8(Data Label) bytes ). Thus, the inner ESADI 
payload, starting with the Intradomain Routeing Protocol 
Discriminator byte, MUST NOT exceed Sz minus 24 for a VLAN ESADI 
instance or Sz minus 28 for an FGL ESADI instance; however, if a 
larger payload is received, it is processed normally (see [RFC6325] 
and [RFC7180] for discussions of Sz and MTU). 


In all cases where this document says that an ESADI PDU is multicast, 
if the transmitting RBridge has only one neighbor and that neighbor 
advertises support for unicast, the PDU MAY be unicast (see 

Section 4.1). 
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A priority bit to indicate that an LSP fragment should be flooded 
with high priority is provided by [RFC7356]. This bit SHOULD be set 
on ESADI-LSP fragment zero because it is important that the ESADI 
Parameter APPsub-TLV get through promptly. This bit SHOULD NOT be 
set on other ESADI-LSP fragments to avoid giving undue priority to 
less urgent PDUs. 


4.3. General Receipt of ESADI PDUS 


In contrast with Layer 3 IS-IS PDU acceptance tests, which check the 
source inner and outer SNPA/MAC in order to verify that a PDU is from 
an adjacent TRILL switch, in TRILL ESADI adjacency is based on the 
system ID, so the system ID inside the PDU is all that is tested for. 


If an ESADI instance believes that it has no ESADI neighbors, it 
ignores any ESADI PDUs it receives. 


4.4. ESADI Reliable Flooding 


The IS-IS reliable flooding mechanism (the Update Process) is 
modified for ESADI in the ways listed below. Except as otherwise 
stated, the ESADI update process works as described in [IS-IS], 
[RFC1195], and [RFC7356]. 


When an ESADI instance sees that it has a new ESADI neighbor, its 
self-originated ESADI-LSP fragments are scheduled to be sent and MAY 
be unicast to that neighbor if the neighbor is announcing in its LSP 
that it supports unicast ESADI (see Section 6.1). If all the other 
ESADI instances for the same Data Label send their self-originated 
ESADI-LSPs immediately, there may be a surge of traffic to that new 
neighbor. Therefore, the ESADI instances SHOULD wait an interval of 
time before sending their ESADI-LSP(s) to a new neighbor. The 
interval time value is up to the device implementation. One 
suggestion is that the interval time can be assigned a random value 
with a range based on the RBridge’s nickname (or any one of its 
nicknames, if it holds more than one), such as ( 2000 * nickname / 
2**16 ) milliseconds, assuming "nickname" to be an unsigned quantity. 


All the TRILL switches participating in an ESADI instance for some 
Data Label appear to ESADI to be adjacent. Thus, the originator of 
any active ESADI-LSP fragment always appears to be on link and, to 
spread the burden of such a response, could be the RBridge to respond 
to any ESADI-CSNP or PSNP request for that fragment. However, under 
very rare circumstances, it could be that some version of the LSP 
fragment with a higher sequence number is actually held by another 
ESADI RBridge on the link, so non-originators need to be able to 
respond eventually. Thus, when the receipt of a CSNP or PSNP causes 
the SRMflag (Send Routing Message flag [IS-IS]) to be set for an LSP 
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fragment, action is as specified in [IS-IS] for the originating ESADI 
RBridge of the fragment; however, at a non-originating ESADI RBridge, 
when changing the SRMflag from 0 to 1, the lastSent timestamp [IS-IS] 
is also set to the current time minus 


minimumLSPTransmissionInterval * Random (Jitter) / 100 


(where minimumLSPTransmissionInterval, Random, and Jitter are as in 
[IS-IS]). This will delay and jitter the transmission of the LSP 
fragment by non-originators. This gives the originator more time to 
send the fragment and provides more time for such an originator- 
transmitted copy to traverse the likely multi-hop path to 
non-originators and clear the SRMflag for the fragment at 
non-originators. 


The multi-hop distribution tree method with Reverse Path Forwarding 
Check used for multicast distribution by TRILL will typically be less 
reliable than transmission over a single local broadcast link hop. 
For LSP synchronization robustness, in addition to sending 
ESADI-CSNPs as usual when it is the DRB, an ESADI RBridge SHOULD also 
transmit an ESADI-CSNP for an ESADI instance if all of the following 
conditions are met: 


o it sees one or more ESADI neighbors for that instance, and 
o it does not believe it is the DRB for the ESADI instance, and 


o it has not received or sent an ESADI-CSNP PDU for the instance for 
the average of the CSNP Time (see Section 6.1) of the DRB and its 
CSNP Time. 


5. End Station Addresses 


The subsections below discuss end station address considerations in 
the context of ESADI. 


5.1. Learning Confidence Level 


The Confidence level mechanism [RFC6325] allows an RBridge campus 
manager to cause certain address learning sources to prevail over 
others. MAC address information learned through a registration 
protocol, such as [802.1X] with a cryptographically based EAP 
[RFC3748] method, might be considered more reliable than information 
learned through the mere observation of data traffic. When such 
authenticated learned address information is transmitted via the 
ESADI protocol, the use of authentication in the TRILL ESADI-LSP 
packets could make tampering with it in transit very difficult. Asa 
result, it might be reasonable to announce such authenticated 
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information via the ESADI protocol with a high Confidence, so it 
would be used in preference to any alternative learning from data 
observation. 


5.2. Forgetting End Station Addresses 


The end station addresses learned through the TRILL ESADI protocol 
should be forgotten through changes in ESADI-LSPs. The timeout of 
the learned end station address is up to the originating RBridge that 
decides when to remove such information from its ESADI-LSPs (or up to 
ESADI protocol timeouts if the originating RBridge becomes 
unreachable). 


If RBridge RBn participating in the TRILL ESADI protocol for Data 
Label X no longer wishes to participate in ESADI, it ceases to 
participate by (1) clearing the ESADI Participation bit in the 
appropriate Interested VLANs or Interested Labels sub-TLV and (2) 
sending a final ESADI-LSP nulling out its ESADI-LSP information. 


5.3. Duplicate MAC Address 


With ESADI, it is possible to persistently see occurrences of the 
same MAC address in the same Data Label being advertised as reachable 
by two or more RBridges. The specification of how to handle this 
situation in [RFC6325] is updated by this document, by replacing the 
last sentence of the last paragraph of Section 4.2.6 of [RFC6325] as 
shown below to provide better traffic-spreading while avoiding 
possible address flip-flopping. 


As background, assume some end station or set of end stations ESn 
have two or more ports with the same MAC address in the same Data 
Label with the ports connected to different RBridges (RB1, RB2, ...) 
by separate links. With ESADI, some other RBridge, RBO, can 
persistently see that MAC address in that Data Label connected to 
multiple RBridges. When RBO ingresses a frame, say from ESO, 
destined for that MAC and label, the current [RFC6325] text permits a 
wide range of behavior. In particular, [RFC6325] would permit RBO to 
use some rule, such as "always encapsulate to the egress with the 
lowest System ID", which would put all of this traffic through only 
one of the egress RBridges and one of the end station ports. With 
that behavior, there would be no load-spreading, even if there were 
multiple different ingress RBridges and/or different MAC addresses 
with the same reachability. [RFC6325] would also permit RBO to send 
different traffic to different egresses by doing ECMP (Equal Cost 
Multipath) at a flow level, which would likely result in return 
traffic for RBO to egress to ESO from various of RB1, RB2, ... for 
the same MAC and label. The resulting address reachability 
flip-flopping perceived at RBO could cause problems. 


Zhai, et al. Standards Track [Page 16] 


RFC 7357 TRILL: ESADI September 2014 


This update to [RFC6325] avoids these potential difficulties by 
requiring that RBO use one of the following two policies: (1) only 
encapsulate to one egress RBridge for any particular MAC and label, 
but select that egress pseudorandomly, based on the topology 
(including MAC reachability) or (2) if RBO will not be disturbed by 
the returning TRILL Data packets showing the same MAC or by label 
flip-flopping between different ingresses, RBO may use ECMP. 

Assuming multiple ingress RBridges and/or multiple MAC and label 
addresses, strategy 1 should result in load-spreading without address 
flip-flopping, while strategy 2 will produce better load-spreading 
than strategy 1 but with address flip-flopping from the point of view 
of RBO. 


OLD [RFC6325] Section 4.2.6 text: 


"... If confidences are also tied between the duplicates, for 
consistency it is suggested that RB2 direct all such frames (or 
all such frames in the same ECMP flow) toward the same egress 
RBridge; however, the use of other policies will not cause a 
network problem since transit RBridges do not examine the 
Inner.MacDA for known unicast frames." 


NEW [RFC6325] Section 4.2.6 text: 


"... If confidences are also tied between the duplicates, then RB2 
MUST adopt one of the following two strategies: 


1. In a pseudorandom way [RFC4086], select one of the egress 
RBridges that is least cost from RB2 and to which the 
destination MAC appears to be attached, and send all traffic 
for the destination MAC and VLAN (or FGL [RFC7172]) to that 
egress. This pseudorandom choice need only be changed when 
there is a change in campus topology or MAC attachment 
information. Such pseudorandom selection will, over a 
population of ingress RBridges, probabilistically spread 
traffic over the possible egress RBridges. Reasonable inputs 
to the pseudorandom selection are the ingress RBridge System ID 
and/or nickname, the VLAN or FGL, the destination MAC address, 
and a vector of the RBridges with connectivity to that MAC and 
VLAN or FGL. There is no need for different RBridges to use 
the same pseudorandom function. 
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6. 


As an example of such a pseudorandom function, if there are k 
egress RBridges (RBO, RB1, ..., RB(k-1)) all reporting 
attachment to address MACx in Data Label DLy, then an ingress 
RBridge RBin could select the one to which it will send all 
unicast TRILL Data packets addressed to MACx in DLy based on 
the following: 


FNV-32(RBin | MACx | DLy | RBO | RB1 | ... | RB(k-1)) mod k 


where the FNV (Fowler/Noll/Vo) algorithm is specified in 
[FNV], RBx means the nickname for RBridge RBx, vals means 
concatenation, MACx is the destination MAC address, DLy is 
the Data Label, and "mod k" means the integer division 
remainder of the output of the FNV-32 function considered as 
a positive integer divided by k. 


2. If RB2 supports ECMP and will not be disturbed by return 
traffic from the same MAC and VLAN (or FGL [RFC7172]) coming 
from a variety of different RBridges, then it MAY send traffic 
using ECMP at the flow level to the egress RBridges that are 
least cost from RB2 and to which the destination MAC appears to 
be attached." 


ESADI-LSP Contents 


The only PDUs used in ESADI are the ESADI-LSP, ESADI-CSNP, and 
ESADI-PSNP PDUs. Currently, the contents of an ESADI-LSP consist of 
zero or more MAC-Reachability TLVs, optionally an Authentication TLV, 
and exactly one ESADI parameter APPsub-TLV. Other similar data may 
be included in the future and, as in [IS-IS], an ESADI instance 
ignores any TLVs or sub-TLVs it does not understand. Because these 
PDUs are formatted as Extended Level 1 Circuit Scope (E-L1CS) PDUs 
[RFC7356], the Type and Length fields in the TLVs are 16-bit. 


This section specifies the format for the ESADI Parameter APPsub-TLV, 
gives the reference for the ESADI MAC-Reachability TLV, and discusses 
default authentication configuration. 


For robustness, the payload for an ESADI-LSP number zero and any 
ESADI-CSNP or ESADI-PSNP covering fragment zero MUST NOT exceed 1470 
minus 24 bytes in length (1446 bytes) if it has an Inner.VLAN, or 
1470 minus 28 bytes (1442 bytes) if it has an Inner.FGL. However, if 
an ESADI-LSP number zero or such an ESADI-CSNP or ESADI-PSNP is 
received that is longer, it is still processed normally. (As stated 
in Section 4.3.1 of [RFC6325], 1470 bytes was chosen to make it 
extremely unlikely that a TRILL control packet, even with reasonable 
additional headers, tags, and/or encapsulation, would encounter MTU 
problems on an inter-RBridge link.) 
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6.1. ESADI Parameter Data 


Figure 4 presents the format of the ESADI parameter data. This 
APPsub-TLV MUST be included in a TRILL GENINFO TLV in ESADI-LSP 
number zero. If it is missing from ESADI-LSP number zero or if 
ESADI-LSP number zero is not known, priority for the sending RBridge 
defaults to 0x40 and CSNP Time defaults to 30. If there is more than 
one occurrence in ESADI-LSP number zero, the first occurrence will be 
used. Occurrences of the ESADI Parameter APPsub-TLV in non-zero 
ESADI-LSP fragments are ignored. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Type | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Length | (2 bytes) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|R| Priority | (1 byte) 
+-+-+-+-+-+-+-+-+ 

| CSNP Time | (1 byte) 
+-+-+-+-+-+-+-+-+ 

| Flags | (1 byte) 
4+--------------- + 

| Reserved for expansion (variable) 
+-+-+-+-... 


Figure 4: ESADI Parameter APPsub-TLV 


Type: Set to ESADI-PARAM sub-TLV (TRILL APPsub-TLV type 0x0001). 
Two bytes, because this APPsub-TLV appears in an extended TLV 
[RFC7356]. 


Length: Variable, with a minimum of 3, but must fit within the ESADI 
packet. This field is encoded as an unsigned integer in network 
byte order [RFC7356]. 


R: A reserved bit that MUST be sent as zero and ignored on receipt. 


Priority: Gives the originating RBridge’s priority for being the DRB 
on the ESADI instance virtual link (see Section 3) for the Data 
Label in which the PDU containing the parameter data was sent. It 
is an unsigned 7-bit integer with the larger magnitude indicating 
higher priority. It defaults to 0x40 for an RBridge participating 
in ESADI for which it has not been configured. 
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CSNP Time: An unsigned byte that gives the amount of time in seconds 
during which the originating RBridge, if it is the DRB on the 
ESADI virtual link, will send at least three ESADI-CSNP PDUs. It 
defaults to 30 seconds for an RBridge participating in ESADI for 
which it has not been configured. 


Flags: A byte of flags associated with the originating ESADI 
instance, as follows: 


0- Gd 2 ay A ao te 4 
4+---+---4---+---4---+---4---+---+ 
| UN| RESV | 
+---+---+---+---+---+---+---+---+ 


The UN flag indicates that the RBridge originating the ESADI-LSP, 
including this ESADI parameter data, will accept and properly 
process ESADI PDUs sent by TRILL unicast (see Section 4.1). The 
remaining RESV bits are reserved for future use and MUST be sent 
as zero and ignored on receipt. 


Reserved for future expansion: Future versions of the ESADI Parameter 
APPsub-TLV may have additional information. A receiving ESADI 
RBridge ignores any additional data here, unless it implements 
such future expansion (s). 


6.2. MAC-Reachability TLV 


The primary information in TRILL ESADI-LSP PDUs consists of 
MAC-Reachability (MAC-RI) TLVs specified in [RFC6165]. These TLVs 
contain one or more unicast MAC addresses of end stations that are 
both on a port and in a VLAN for which the originating RBridge is 
Appointed Forwarder, along with the l-octet unsigned Confidence in 
this information with a value in the range 0-254. If such a TLV is 
received containing a Confidence of 255, it is treated as if the 
Confidence was 254. (This is to assure that any received address 
information can be overridden by local address information statically 
configured with a Confidence of 255.) 


The TLVs in TRILL ESADI PDUs, including the MAC-RI TLV, MUST NOT 
contain the Data Label ID. If a Data Label ID is present in the 
MAC-RI TLV, it is ignored. In the ESADI PDU, only the Inner.VLAN or 
Inner.FGL tag indicates the Data Label to which the ESADI-LSP 
applies. 
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6.3. Default Authentication 


The Authentication TLV may be included in ESADI PDUs [RFC5310] 
[IS-IS]. The default for ESADI PDU authentication is based on the 
state of TRILL IS-IS shared secret authentication for TRILL IS-IS LSP 
PDUs. If TRILL IS-IS authentication and ESADI are implemented at a 
TRILL switch, then ESADI MUST be able to use the authentication 
algorithms implemented for TRILL IS-IS and implement the keying 
material derivation function given below. If ESADI authentication 
has been manually configured, that configuration is not restricted by 
the configuration of TRILL IS-IS security. 


If TRILL IS-IS authentication is not in effect for LSP PDUs 
originated by a TRILL switch, then ESADI PDUs originated by that 
TRILL switch are by default also unsecured. 


If such IS-IS LSP PDU authentication is in effect at a TRILL switch, 
then, unless configured otherwise, ESADI PDUs sent by that switch 
MUST use the same algorithm in their Authentication TLVs. The ESADI 
authentication keying material used is derived from the IS-IS LSP 
shared secret keying material as detailed below. However, such 
authentication MAY be configured to use some other keying material. 


HMAC-SHA256 ( "TRILL ESADI", IS-IS-LSP-shared-key ) 


In the algorithm above, HMAC-SHA256 is as described in [FIPS180] and 
[RFC6234], and "TRILL ESADI" is the 11-byte US ASCII [ASCII] string 
indicated. IS-IS-LSP-shared-key is secret keying material being used 
by the originating TRILL switch for IS-IS LSP authentication. 


7. IANA Considerations 


IANA allocation and registry considerations are given below. Three 
new sub-registries have been created in the "Transparent 
Interconnection of Lots of Links (TRILL) Parameters" registry located 
at <http://www.iana.org/assignments/trill-parameters> -- two in 
Section 7.1 and one in Section 7.2 -- and various code points have 
been assigned. 
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7.1. ESADI Participation and Capability Flags 
IANA Action 1: 

IANA has created the following new sub-registry called "Interested 

VLANs Flag Bits" in the "Transparent Interconnection of Lots of 

Links (TRILL) Parameters" registry. 
Sub-registry: Interested VLANs Flag Bits 
Registration Procedures: IETF Review 
Note: These bits appear in the Interested VLANs record within 
the Interested VLANs and Spanning Tree Roots Sub-TLV (INT-VLAN) 
specified in [RFC7176]. 


References: [RFC7176], [RFC7357] 


Bit Mnemonic Description Reference 
0 M4 IPv4 Multicast Router Attached [RFC7176] 
1 M6 IPv6 Multicast Router Attached [RFC7176] 
2 = Unassigned 
3 ES ESADI Participation [RFC7357] 
4-15 a (used for a VLAN ID) [RFC7176] 
16-19 z Unassigned 
20-31 = (used for a VLAN ID) [RFC7176] 


The creation of this sub-registry (as immediately above) assigned 
bit 3 as the ESADI Participation bit in the Interested VLANs and 
Spanning Tree Roots sub-TLV. If The ESADI Participation bit is a 
one, it indicates that the originating RBridge is participating in 
ESADI for the indicated Data Label(s). 


TANA Action 2: 
IANA has created the following new sub-registry called "Interested 
Labels Flag Bits" in the "Transparent Interconnection of Lots of 
Links (TRILL) Parameters" registry. 
Sub-registry: Interested Labels Flag Bits 
Registration Procedures: IETF Review 
Note: These bits appear in the Interested Labels record within 


the Interested Labels and Spanning Tree Roots Sub-TLV 
(INT-LABEL) specified in [RFC7176]. 
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References: [RFC7176], [RFC7357] 


Bit Mnemonic Description Reference 

0 M4 IPv4 Multicast Router Attached [RFC7176] 

1 M6 IPv6 Multicast Router Attached [RFC7176] 

2 BM Bit Map [RFC7176] 

3 ES ESADI Participation [RFC7357] 
4-7 - Unassigned 


The creation of this sub-registry (as immediately above) assigned 

bit 3 as the ESADI Participation bit in the Interested Labels and 

Spanning Tree Roots sub-TLV. If The ESADI Participation bit is a 

one, it indicates that the originating RBridge is participating in 
ESADI for the indicated Data Label(s). 


TBs TRILL GENINFO TLV 
IANA Action 3: 


IANA has allocated the IS-IS Application Identifier 1 under the 
Generic Information TLV (#251) [RFC6823] for TRILL. 


IANA Action 4: 


IANA has created a sub-registry in the "Transparent 
Interconnection of Lots of Links (TRILL) Parameters" registry as 
follows: 


Sub-registry: TRILL APPsub-TLV Types under IS-IS TLV 251 
Application Identifier 1 


Registration Procedures: IETF Review with additional 
requirements on the documentation of the use being 
registered as specified in Section 7.2 of [RFC7357]. 


Note: Types greater than 255 are only usable in contexts 
permitting a type larger than one byte, such as extended TLVs 
[RFC7356]. 


Reference: [RFC7357] 
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Type Name Reference 
0 Reserved [RFC7357] 
1 ESADI-PARAM [RFC7357] 
2-254 Unassigned [RFC7357] 
255 Reserved [RFC7357] 
256-65534 Unassigned [RFC7357] 
65535 Reserved [RFC7357] 


TRILL APPsub-TLV Types 2 through 254 and 256 through 65534 are 
available for assignment by IETF Review. The RFC causing such an 
assignment will also include a discussion of security issues and 
of the rate of change of the information being advertised. TRILL 
APPsub-TLVs MUST NOT alter basic IS-IS protocol operation 
including the establishment of adjacencies, the update process, 
and the decision process for TRILL IS-IS [IS-IS] [RFC1195] 
[RFC7177]. The TRILL Generic Information TLV MUST NOT be used in 
an IS-IS instance zero [RFC6822] LSP but may be used in Flooding 
Scoped LSPs (FS-LSPs) [RFC7356]. 


The V, I, D, and S flags in the initial flags byte of a TRILL Generic 
Information TLV have the meanings specified in [RFC6823] but are not 
currently used, as TRILL operates as a Level 1 IS-IS area and no 
semantics are hereby assigned to the inclusion of an IPv4 and/or IPv6 
address via the I and V flags. Thus, these I and V flags MUST be 
zero; however, if either or both are one, the space that should be 
taken by an IPv4 and/or IPv6 address, respectively, is skipped over 
and ignored. Furthermore, the use of multilevel IS-IS is an obvious 
extension for TRILL [MultiLevel], and future IETF Standards Actions 
may update or obsolete this specification to provide for the use of 
any or all of these flags in the TRILL GENINFO TLV. 


The ESADI Parameters information, for which TRILL APPsub-TLV 1 is 
hereby assigned, is compact and slow changing (see Section 6.1). 


For security considerations related to ESADI and the ESADI Parameter 
APPsub-TLV, see Section 8. 


8. Security Considerations 


ESADI PDUs can be authenticated through the inclusion of the 
Authentication TLV [RFC5310]. Defaults for such authentication are 
described in Section 6.3. 


The ESADI-LSP data primarily announces MAC address reachability 
within a Data Label. Such reachability can, in some cases, be an 
authenticated registration (for example, a Layer 2 authenticated 
registration using cryptographically based EAP (Extensible 
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Authentication Protocol [RFC3748]) methods via [802.1X]). The 
combination of these techniques can Cause ESADI MAC reachability 
information to be substantially more trustworthy than MAC 
reachability learned from observation of the data plane. 
Nevertheless, ESADI still involves trusting all other RBridges in the 
TRILL campus, at least those that have the keying material necessary 
to construct a valid Authentication TLV. 


However, there may be cases where authenticated registration is used 
for end stations, because of a significant threat of forged packets 
on end station links, but it is not necessary to authenticate ESADI 
PDUs because that threat is not present for inter-RBridge trunks. 
For example, a TRILL campus with secure RBridges and inter-RBridge 
links configured as trunks but with some end stations connected via 
IEEE 802.11 wireless access links might use 802.11 authentication for 
the connection of such end stations but might not necessarily 
authenticate ESADI PDUs. Note that if the IS-IS LSPs in a TRILL 
campus are authenticated, perhaps due to a concern about forged 
packets, the ESADI PDUs will be authenticated by default as provided 
in Section 6.3. 


MAC reachability learned from the data plane (the TRILL default) is 
overwritten by any future learning of the same type. ESADI 
advertisements are represented in the Data Label scoped link state 
database. Thus, ESADI makes visible any multiple attachments of the 
same MAC address within a Data Label to different RBridges (see 
Section 5.3). This may or may not be an error or misconfiguration, 
but ESADI at least makes it explicitly and persistently visible, 
which would not be the case with data plane learning. 


For general TRILL security considerations, see [RFC6325]. 
8.1. Privacy Considerations 
The address reachability information distributed by ESADI has 


substantial privacy considerations under many, but not all, 
circumstances. 


For example, if ESADI were used in a TRILL campus with independent 
user end stations at the edge, the MAC addresses of such end stations 
could uniquely identify the users of those end stations. Their 
reachability would be sensitive information and, particularly if 
logged, could reveal such user information. On the other hand, if 
TRILL is being used to implement an Internet Exchange Point (IXP) to 
connect Internet Service Providers (ISPs), the MAC addresses being 
advertised in ESADI would typically be those of the ISP’s directly 
connected IP router ports, since Layer 3 routers bound the TRILL 
campus, for which there would be few privacy concerns. 
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10. 


10. 


However, records of MAC attachment that include a modest amount of 
history, perhaps a few days' worth, can be useful in managing a 
network and troubleshooting network problems. It might, in some 
cases, also be legally required, or required for billing purposes or 
the like. 


Network operators should seek a reasonable balance between these 
competing considerations, customized for the circumstances of their 
particular networks where ESADI is in use. They should not maintain 
logs of MAC reachability information for any longer than is clearly 
required. 
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Appendix A. Interoperability and Changes to RFC 6325 


This appendix summarizes the significant changes this document makes 
to the TRILL base protocol specification [RFC6325]. Although 
simultaneous use of [RFC6325] ESADI and ESADI as specified in this 
document in a TRILL campus is very unlikely due to non-deployment of 
[RFC6325] ESADI, this appendix also discusses, for each change, the 
interoperability considerations should such simultaneous use occur. 


A.1. ESADI PDU Changes 


The format of ESADI-LSP, ESADI-CSNP, and ESADI-PSNP PDU payloads is 
changed from the IS-IS Level 1 format [IS-IS] to the Extended Level 1 
Circuit Scope format (E-L1CS) specified in [RFC7356]. This change is 
not backwards compatible with [RFC6325]. It is made in light of the 
information-carrying capacity of the E-L1CS format, which is 

256 times greater than that of the base IS-IS format. It is 
anticipated that this greater information-carrying capacity will be 
needed, under some circumstances, to carry end station addressing 
information or other similar address and reachability information 
when it is added to ESADI in the future. 


The PDU numbers used for the ESADI LSP, CSNP, and PSNP PDUs in 
[RFC6325] are 18, 24, and 26 [IS-IS]. With this document, the format 
changes, and the PDU numbers change to 10, 11, and 12 [RFC7356]. The 
use of different PDU numbers assures that a PDU will not be 
mis-parsed. Because of this, implementations of this document and 
implementations of [RFC6325] ESADI will discard each other’s PDUs. 
Thus, address reachability or other information distributed through 
either type of ESADI implementation will only be communicated to 
other implementations of the same type, and the two communities will 
not communicate any information with each other. 


Note that RBridges can use the TRILL mandatory-to-implement, 
enabled-by-default data plane address learning in addition to ESADI. 
(Section 5 of this document and the material it references explain 
how to handle conflicts between different sources of address 
reachability information.) Simply leaving data plane address 
learning enabled would enable smooth incremental migration from 
[RFC6325] ESADI to the ESADI specification in this document, should 
that be necessary. The data plane address learning would fill in any 
gaps due to non-communication between the two types of ESADI 
implementations, although without the speed or security advantages 
of ESADI. 
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A.2. Unicasting Changes 


Unicasting of ESADI PDUs is optionally supported, including replacing 
Section 4.6.2.2 of [RFC6325] with the new text given in Section 4.1 


of this document. This unicast support is backwards compatible 
because it is only used when the recipient RBridge signals its 
support. 


A.3. Message Timing Changes and Suggestions 


The following timing-related ESADI message changes and suggestions 
are included in this document: 


1. Provide for staggered delay for non-originators of ESADI-LSP 
fragments in response to requests for such fragments by CSNP and 
PSNP messages. 


2. Suggest staggered timing of unicast ESADI-LSPs when a new ESADI 
RBridge appears on the ESADI virtual link. 


These relate only to the timing of messages for congestion 
minimization. Should a message be lost, due to congestion or 
otherwise, it will be later retransmitted as a normal part of the 
robust flooding mechanism used by ESADI. 


A.4. Duplicate Address Reachability 


The handling of persistent reachability of the same MAC within the 
same Data Label from two or more RBridges is substantially modified, 
including the explicit replacement of some text in Section 4.2.6 of 
[RFC6325] (see Section 5.3 of this document). There is no problem 
with a mixture of ESADI implementations in a TRILL campus, some 
conforming to [RFC6325] and some conforming to this document, for 
handling this condition. The more implementations conform to the 
improved behavior specified in this document for this condition, the 
better the traffic-spreading will be, and the less likely address 
flip-flopping problems will be. 
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